Fix DrawOnlyWidget rendering problems - #48

This causes conflicts for now...

Solved this with an agent so i will paste its report:

Rebased onto main and squashed into a single commit. The conflict was only in the Context
struct: segStack/segStackIdx and the new inLayoutCallback field landed in the same spot.

Two things changed since the original patch:

• the layout callback state is now saved and restored, so a nested GridCell does not clear it
  for the enclosing callback. Without that, a DrawOnlyWidget placed after an inner GridCell
  falls back to the old path and the widget disappears again.
• added TestDrawOnlyWidgetInGridCellDuringScroll, which fails on the current main (the draw
  command for a still visible cell is culled once the cell's first layout item scrolls out) and
  passes with the fix.

The vector.DrawFilledRect -> vector.FillRect rename is unrelated cleanup (deprecated since
v2.9), and the visibility check now uses the clip rect instead of the container body bounds.
I can drop either one if you'd rather keep this on the fix only.

CI is green on Go 1.25/1.26/1.27 for Linux, macOS and Windows.

I found a layout regression in the new inLayoutCallback handling (draw.go:211).

The flag remains true inside a Panel nested in GridCell, even though the panel has its own layout. As a result, a DrawOnlyWidget directly inside that panel skips allocating its row. Subsequent widgets move into the custom drawing's space, and the panel's scrollable content size is undercounted.

A minimal reproduction is this structure:

ctx.SetGridLayout(nil, []int{300})
ctx.GridCell(func(image.Rectangle) {
	ctx.SetGridLayout(nil, []int{250})
	ctx.Panel(func(layout debugui.ContainerLayout) {
		ctx.SetGridLayout(nil, []int{150})
		ctx.DrawOnlyWidget(func(*ebiten.Image) {})
		ctx.GridCell(func(bounds image.Rectangle) {
			// Inspect bounds.Min.Y - layout.BodyBounds.Min.Y.
		})
	})
})

I verified that the following cell's vertical offset is 159 pixels on the base and only 5 pixels with this PR. The same panel outside the enclosing GridCell still produces 159 pixels. A focused regression test passes on the base and fails with the PR; the existing test suite passes with the PR.

Could the flag be scoped to the layout that owns the callback, or saved/reset/restored when entering an independent container layout? That should preserve the scrolling fix without changing layout allocation inside nested panels.

Review comment authored by Codex (OpenAI), on behalf of @hajimehoshi.

Following up on the nested-panel regression: I would favor preserving DrawOnlyWidget's existing layout allocation and removing only its bounds-based visibility check, without introducing inLayoutCallback.

The callback can draw beyond the row allocated by layoutNext(), so that row's bounds cannot reliably determine whether its output is visible. The current clip rectangle already limits the drawing. For example:

func (c *Context) DrawOnlyWidget(f func(screen *ebiten.Image)) {
	_ = c.wrapEventHandlerAndError(func() (EventHandler, error) {
		if _, err := c.layoutNext(); err != nil {
			return nil, err
		}

		c.setClip(c.clipRect())
		defer c.setClip(unclippedRect)

		cmd := c.appendCommand(commandDraw)
		cmd.draw.f = f
		return nil, nil
	})
}

This would keep row allocation consistent for standalone calls and calls inside nested panels, while allowing drawing in a partially visible grid cell to continue. It also avoids making layout allocation depend on whether an ancestor is currently running a layout callback. No change to other widgets' visibility checks is needed for this approach.

The tradeoff is that offscreen callbacks would still execute. The proposed inLayoutCallback path already does that for the reported grid-cell case; reliable culling would require explicit bounds for the callback's drawing.

This is a suggested alternative, not a tested patch. I would validate it against both the scrolling regression and the nested-panel layout regression described above.

Comment authored by Codex (OpenAI), on behalf of @hajimehoshi.

The simplified implementation looks good. Could you remove the two added tests and the DrawCommandCount helper from this PR?

The command-count test exposes internal drawing bookkeeping and requires exactly five queued commands, without verifying the visible rendering. The nested-panel test uses public behavior, but it primarily guards against the now-removed inLayoutCallback approach. For this small fix, manually checking the original scrolling reproduction is sufficient; these additional tests are not necessary.

Please also fix the import grouping in debugui_test.go: standard library first, external dependencies second, and the current module (github.com/ebitengine/debugui) in a separate final group. Removing these tests should make the newly added Ebitengine import unused, in which case it can simply be removed.

Comment authored by Codex (OpenAI), on behalf of @hajimehoshi.